The present application relates generally to security in computer networks and computing systems, and more particularly, but not exclusively, to the inspection of encrypted data in high availability deployments.
An increasing number of computer applications use a secure connection between clients and servers on computer networks, such as the Internet. Numerous communication protocols exist to provide secure connections. For example, Secure Sockets Layer (SSL) and Transport Layer Security (TLS) can provide secure communications. The Institute of Electrical and Electronics Engineers (IEEE) deprecated SSL in favor of TLS.
TLS provides a secure connection because it encrypts the data being sent between the client and the server during a communication session. Although the connection may be secure, if the connection is to a malicious server, then the network could be exposed to dangerous viruses, trojans, or network attacks hidden in the encrypted data. Therefore, enterprises need to perform network inspection or monitoring of the encrypted traffic on the secure links to inspect for malicious data. To inspect encrypted traffic, there needs to be a means to decrypt the data payload, such as obtaining the private key used for encryption/decryption by the sender/receiver. For example, with TLS connections prior to TLS release 1.3, servers often used RSA certificates to perform key exchanges with the client, and “inspectors” used the private key from the server's RSA certificate to decrypt the payload data for inspection. As used herein, an “inspector” refers to software, hardware, and/or a combination of hardware and software configured to receive data, decrypt the data, examine the data for malicious content, extract or neutralize any malicious content in the data, encrypt non-malevolent data, and transmit encrypted data.
The use of RSA certificates presents a weakness in security because if the server's RSA private key is compromised then all TLS communications to that server can be decrypted. This includes traffic that may have been captured in the past. For instance, if a malicious party captured traffic to a server for three years and at the end of this time obtained the RSA certificate, then the malicious party could decrypt all of that traffic.
To eliminate this weakness, TLS release 1.3 deprecates the use of RSA in order for TLS release 1.3 to provide “Perfect Forward Secrecy” in which each key is valid only for one session. Because TLS 1.3 does not use RSA, inspectors require an alternative means for decrypting the payload. Man-in-the-middle (“MitM”) inspection offers one such alternative. In MitM inspection, an inspector intercepts the client's connection to a server, establishes the connection to the server on the client's behalf, decrypts the data, inspects the data, and then re-encrypts the data for transport to the client.
In High Availability (“HA”) deployments of network connectivity in which a high level of operational performance is required, multiple MitM inspectors may be needed to inspect a single secure communications session. This becomes problematic because the inspection states must be synchronized between inspectors so that all inspectors for a given communication session use the same keys for encrypting/decrypting. This is true whether the deployment of inspectors is in the active-active or active-passive inspection format.
Mechanisms to synchronize the inspection states between inspectors, including the session data and session keys are extremely complex, error-prone, and they create new race conditions between inspectors.